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Abstract. In this report, we present functional models for software and hard- 
ware components of Time-Triggered Systems on a Chip (TTSoC). These are 
modeled in the asynchronous component based language BIP. We demonstrate 
the usability of our components for simulation of software which is developed 
for the TTSoC. Our software comprises services and an application part. Our ap- 
proach allows us to simulate and validate aspects of the software system at an 
early stage in the development process and without the need to have the TTSoC 
hardware at hand. 

1 Introduction 

Simulation and analysis of systems at an early stage in the development process al- 
lows the identification of problems prior to the systems deployment. Thus, it can save 
development costs. 

In this paper we present an approach that allows the simulation of application soft- 
ware parts of embedded systems without the hardware and low level software drivers 
and operating system. In particular we are targeting systems based on Time-Triggered 
Systems on a Chip (TTSoC) |9| hardware. TTSoC are multi core systems where hosts 
- usually comprising at least a core and local memory - communicate at pre-defined 
periodic times with each other. All hosts are integrated on one chip. Thus, it is possible 
to achieve time guarantees for messages sent between different hosts. This guaranteed 
behavior facilitates certification, e.g., in the automotive or avionics industry. Cores may 
be specialized, e.g., for application code - our deployment scenarios typically feature 
one piece of software which controls the rest of the system called application - and 
I/O. We formally describe an abstract model of the TTSoC in software using the BIP 
(Behavior, Interaction, Priority |2|) modeling language. This allows us to simulate soft- 
ware parts of the system prior to the deployment on the hardware. The deployment may 
be an expensive process, in some cases the hardware might even not be available at 
the start of a development project. Using our approach we are able to simulate soft- 
ware and hardware -parts of a system in software. This enables us to test software which 
can interact with the simulated software and hardware parts (software-in-the-loop). Our 
BIP model allows the simulation of application and I/O communication parts running 
on different cores. Our simulation aims particularly at causal dependencies between 
components and their interactions. These aspects behave in the same way as in the non- 
simulated system. Causal dependencies is an important aspect in multi-core systems 



and even more crucial in TTSoC based systems. Furthermore, our models represent 
some architectural features of the system. 

In this paper we target TTSoC systems for controlling industrial automation devices. 
As a case study we are describing the BIP based simulation code which is needed to 
simulate the apphcation software which controls a sorting station (Figure[T]) used in the 
industrial automation domain. The main contributions of this paper are the BIP models 




Fig. 1: Sorting machine overview 



of the TTSoC system, the case study, and a method to integrate generated C code pieces 
from tool chains used in the industrial automation domain into BIP models that simulate 
the industrial automation domain. 

1.1 Related Work 

The Distribution Operation Layer (DOL) |151 is used for the analysis of embedded 
multiprocessor systems. DOL can be used for system performance analysis as well as 
optimization / design space exploration tasks, like scheduling of applications. The Uni- 
fied Modeling Language (UML) |12 |, a system modeling language, is used to specify, 
construct, modify and visualize object-oriented software systems. Another approach 
for modeling and simulating real-time embedded systems is developed in the Ptolemy 
project |8|. Furthermore, a language originally driven by the avionics industry for sim- 
ulating for the analysis and specification of hardware and software architectures is 
AADL 1 7 1 . For other languages and notations specific to tools, we can mention Simulink 
/ Stateflow that is used to model and simulate event-driven systems; SystemC ifTTl . a 
standard design and verification language built in C++; Metropolis 11], an environment 
for complex heterogeneous electronic system design that supports simulation, verifica- 
tion and synthesis; and IF-toolset [6|, an environment for modeling and validation of 
heterogeneous real-time systems. 

In contrast to our work carried out using BIP the real-time aspects and precise timing 
conditions are of greater importance in these approaches. Thus, our models are more 



abstract and simpler to use. Simulating systems on the more abstract level is justified 
by the fact that we do not know the full timing properties of our system at simulation 
time. Hardware specifications might also be subject to change at the time we run our 
simulations. In our work we rather want to find out possible constraints that need to be 
fulfilled by running a randomized simulation. These constraints are taken into account 
during the implementation by, e.g., ensuring that certain code parts meet an upper bound 
execution deadline by using a Worst-Case Execution Time Analysis tool. 

A formal study and modeling of some aspects of the same sorting station from the 
industrial automation domain that we describe in this paper can be found in [5]. The Coq 
theorem prover [13 ] is used to prove some properties of the lEC 61131-3 model ifTOl 
of this same station. However, TTSoC aspects are not regarded in this Coq based work. 

1.2 Overview 

An overview on the BIP language is given in Section |2] Section [3] describes Time- 
Triggered Systems on a Chip and Section |4] presents their modeling in BIP. A case 
study simulating the application software controlling an industrial automation device is 
featured in Section|5] A short evaluation is given in Section|6] A conclusion is given in 
Section|2l 

2 BIP - Behavior Interaction Priority 

In this section we recall the necessary concepts of the BIP framework fT\. BIP is a 
component-based framework for constructing systems by superposing three layers of 
modeling: Behavior, Interaction, and Priority. The behavior layer consists of a set of 
atomic components represented by transition systems. The interaction layer models 
the collaboration between components. Interactions are described using sets of ports 
and connectors between them. The priority layer is used to enforce scheduling policies 
applied to the interaction layer, given by a strict partial order on interactions. 

2.1 Component-based Construction 

BIP offers primitives and constructs for modeling and composing complex behaviors 
from atomic components. Atomic components are Labeled Transition Systems (LTS) 
extended with C/C++ functions and data. Transitions are labeled with sets of commu- 
nication ports. Composite components are obtained from atomic components by speci- 
fying connectors and priorities. 

Atomic Components An atomic component is endowed with a set of local variables 
X taking values in a domain D. A valuation of the set X is a function of X ^ D that 
maps each variable to a value. Atomic components synchronize and exchange data with 
other components through the notion of port. 

Definition 1 (Port). A port p[X'], where X' C X, is defined by a port identifier p and 
some data variables in a set X' ( referred as the support set). 



Definition 2 (Atomic component). An atomic component B is defined as a tuple (P, L, 

T, X, {ffrlreT, {/r}reT), wherej 

— (P, L, T) is an LTS over a set of ports P. L is a set of control locations and T C 
L X P X L is a set of transitions. 

— X is a set of variables. 

— For each transition t e T: 

• is a boolean condition over a valuation of X: the guard of t, 

• /t- is the computation step ofr, a list of statements. 

For r — {l,p,l') e T a transition of the internal LTS, I (resp. /') is referred as the 
source (resp. destination) location and p is a port through which an interaction with 
another component can take place. Moreover, a transition r = {l,p,l') e P in the 
internal LTS involves a transition in the atomic component of the form {l,p,gr, fr, I') 
which can be executed only if the guard gr evaluates to true, and is a computation 
step consisting of transformations of local variables in X. 

Example: Atomic component "Global timer" Figure |2] shows the global timer (clock) 
used in our TTSoC that we modeled as an example of an atomic component. 




Fig. 2: Atomic component 



This atomic component has a port tick, a control location li and a variable time 
that is associated to the port tick and is increased every time the transition tick occurs. 
The absence of guard on the transition tick implies that its guard is always true. 

Semantics of Atomic Components. The semantics of an atomic component is an LTS 
over configurations and ports, formally defined as follows: 

Definition 3 (Semantics of Atomic Components). The semantics of the atomic com- 
ponent (P, P, P, X, {gr}r(^T, {/tItst) « an LTS (P, Q, P') s.t. 

- Q = P X [X ^ D], 

- P' = {((/,«), p, (/',«')) e Q X Px I 3t = e P : gr{v)^v' = fr{v)}. 

A configuration is a pair (Z, v) E Q where Z e P is a control location, and v E [X ^ 

D] is a valuation of the variables in X. The evolution of configurations {li, v) ''\ 
{I2, v'), where Vp is a valuation of variables attached to port p, is possible if there exists 
a transition (/i,p[Xp], g,-, s.t. gr{v) = true. As a result, the valuation v of 
variables is modified to v' = fT-{v[Xp <— Vp]). 



Creating composite components. Assuming some available atomic components Bi , 
. . . , Bn, we show how to connect {Bi}i^j with / C [1, n] using connectors. 

A connector 7 is used to specify possible interactions, i.e. the sets of ports that have 
to be jointly executed. Two types of ports (synchron, trigger) are defined, in order to 
specify the feasible interactions of a connector. A trigger port is active: it can initiate 
an interaction without synchronizing with other ports. It is represented graphically by 
a triangle. A synchron port is passive: it needs synchronization with other ports for 
irritiating an interaction. It is denoted by a circle. A feasible interaction of a connector 
is a subset of its ports s.t. either it contains some trigger, or it is maximal. 
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Fig. 3: Rendez-vous and broadcast 
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Fig. 4: A TTSoC connector with data transfer 



Figure|3]shows two connectors: Rendezvous (only the maximal interaction Sirir2rz 
is possible). Broadcast (all the interactions containing the trigger port si are possible). 
Formally, a connector is defined as follows: 

Definition 4 (Connector). A connector 7 is a tuple {V^, t, G, F), where: 

- r^^ {p^[x,] I K e B,.p},ei s.t. yi&i -.r-yn b,.p = {p,}, 

- t : V~f — > B i.f. t{p) = true ifp is trigger (and false if synchron), 

- G is a Boolean function over the set of variables Uig/X^ (the guard), 

- F is an update function defined over the set of variables Uig/Xi. 



V-y is the set of connected ports called the support set of 7. The ports in V-, are tagged 
with function t indicating whether they are trigger or synchron. Moreover, for each 
i G /, is a set of variables associated to the port pi. 

A communication between the atomic components of through a connector 

{V-^, G, F) is defined using the notion of interaction: 

Definition 5 (Interaction). A set of ports a — {pj}j(zj C V-, for some J C I is an 
interaction ofj if one of the following conditions holds: (1) there exists j (z J s.t. pj is 
trigger; (2) for all j G J, Pj is synchron and {Pj}j(£j — V^. 

An interaction a has a guard and two functions Ga, Fa, respectively obtained by pro- 
jecting G and F on the variables of the ports involved in a. We denote by 1(7) the set of 
interactions of 7. Synchronization through an interaction involves two steps. First, the 
guard Ga is evaluated, then the update function Fa is applied. If there are several possi- 
ble interactions inside a connector, we choose the interaction involving the maximurrQ 
number of ports. One can also add priorities to reduce non-determinism whenever sev- 
eral interactions are enabled. Then, the interaction with the highest priority is chosen. 

In the TTSoC system that we modeled, the global timer communicates with all 
the components that need to synchronize their action according to some time sched- 
ule. These communications are done by using interactions between the global timer 
and these components. Figure]?] represents a connector with data transfer used in the 
TTSoC model. It connects two ports core2tissjio of a communication service compo- 
nent Gomm and of a TISS component. These ports have their own associated message 
variables msg. The message variable of the Comm component is sent over the connec- 
tor to the TISS component {TISS.msg = Comm.msg). 

Definition 6 (Composite Component). A composite component is defined from a set 
of available atomic components and a set of connectors. The connection of the {_Bj}ig/ 
using the set F of connectors is denoted _r({_Bi}ig/). 

Note that a composite component obtained by composition of a set of atomic compo- 
nents can be composed with other components in a hierarchical and incremental fashion 
using the same operational semantics. 

Definition 7 (Semantics of Composite Components). A state q of a composite com- 
ponent G ~ F{Bi, . . . , Bn), where F connects the Bi's for i £ F is a n-tuple 
q — {qi,...,qn) where qi — {li,Vi) is a state of Bi. Thus, the semantics of G is 

precisely defined as a transition system (Q, A, — >), where: 

- Q = Bi.Qx ...xB^.Q, 

- A = {a € I(7)}-yg r is the set of all possible interactions, 

- — y is the least set of transitions satisfying the following rule: 

3^eF:-, = {P^,G,F) 3a G 1(7) GaiviX)) 

Vz € / : q, q[^v^ = Fai{v{X)) ^ I : q, = q'^ 

{qi, ■ ■ • {q'l, • ■ • ,9^) 

where a = {pi}i^i, X is the set of attached variables on the ports of a, v is 
the global valuation of variables, and Fai is the partial function derived from F 
restricted to the variable associated to pi. 

' If there are several maximal interactions, the choice between them is at random. 



The meaning of the above rule is the following: if there exists an interaction a s.t. aU its 
ports are enabled in the current state and its guard (Ga{v{X))) is true, then we can fire 
the interaction. When a is fired, not involved components stay in the same state, and, 
involved components evolve according to the interaction. 

Notice that several distinct interactions can be enabled at the same time, thus in- 
troducing non-determinism in the product behavior, possibly restricted using priorities. 

Definition 8 (Priority). Let C = {Q, A, — !•) be the behavior of the composite com- 
ponent r{Bi , . . . , Bn)- A priority model tt is a strict partial order on the set of interac- 
tions A. Given a priority model tt, we abbreviate (a, a') € n to a ^ a'. The component 
7r(C) is defined by the behavior {Q, A, — >Tr), where — >^ is the least set of transitions 
satisfying the following rule: 

q^q' ^a! E A, 3q" e Q : a < a' A q ^ q" 

q — >TT q 

An interaction is enabled in 7r(C) only if it is enabled in C, and, it is maximal according 
to TT among the active interactions in C. 

Finally, we consider systems defined as a parallel composition of components to- 
gether with an initial state. 

Definition 9 (System). A system S is a pair (B, Init) where B is a component and 
Init is the initial state of B. 



3 Time-Triggered Systems on a Chip 

In a TTSoC several hosts communicate with each other using a time-triggered network. 
Hosts and time-triggered network are integrated on one chip. 

In this paper, we follow the TTSoC description given in [9J. A TTNoC consists of 
the following components: 

- Hosts are physical entities that interact via a time-triggered network with each 
other. In many cases a host is a CPU Core equipped with its own memory and 
possible local I/O access. Cores provide computation power Distinct cores can be 
used for handling different I/O tasks. Apart from cores, hosts can be connections to 
other bus systems or related I/O devices. 

- Hosts are connected via a Time-Triggered Network on a Chip (TTNoC). 

The TTNoC provides communication channels between the hosts. For each appli- 
cation purpose the TTNoC is configured in a way such that messages of fixed length 
can be sent between the different cores in distinct time slots. In our case (follow- 
ing |9 1) we are looking at a TTNoC which is organized using a mesh structure. This 
means that different parts of communication channels are connected via switches 
which route messages through the network. One consequence - and advantage over 
bus like structures - is that unlike in traditional bus-systems different hosts may be 
communicating at the same time as long as their communication channel parts and 
switches do not interfere with each other. 



- The connection between a host and a TTNoC is guarded using a Trusted Inter- 
face Subsystem (TISS) which serves as an interface and intermediate storage for 
the host thereby abstracting some TTNoC details and ensuring that time slots and 
routes for messages are met. 

An example TTSoC is shown in Figure |5] One can see that six hosts are connected 
via TISS to the TTNoC. Two of the switches are directly connected to two TISS. The 
other two switches are each connected to only one TISS. The switches are connected 
with each other realizing a 2x2 grid. One can see that parallel communication is in some 
cases possible, e.g., Host 1 with Host 4, Host 5 with Host 6 and Host 2 with Host 3 can 
exchange messages in the same time slot. 
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Fig. 5: TTSoC overview 



4 Modeling the TTNoC in BIP 



Here we give a description of the TTNoC components and their connection to the envi- 
ronment using TISS. We present their modeling using BIP. 



4.1 Managing Time 



Time-triggered systems are characterized by the fact that the communication between 
different hosts is done in a synchronous time-triggered way whereas the hosts them- 
selves may internally behave in an asynchronous way and the interaction with the TISS 
may also behave asynchronously. 

Global Time Our model features a component which emits a global time tick (cf. Fig- 
ure[2]i. Different parts of our BIP model can use this time tick, e.g., for synchronization. 

Splitting of the global time tick into subticks In the TTNoC BIP model at hand a global 
time tick tick is followed by three subticks t1 , 12 and t3 that represent internal steps that 
are taken to transmit a message between different TISS via the TTNoC switches. Thus, 
we have four ticks which may be used to transmit a message between a TISS and a 
switch, transmit a message between this switch and another switch, transmit a message 
between this other switch and yet another switch, and finally transmit it to another TISS. 
Thus, routes through the TTNoC may comprise at most three switches. The time tick 
splitting is modeled as an independent BIP component. Larger TTNoC would require 
the modeling of additional subticks. 

4.2 Tlie TISS 

A TISS has two main purposes: 

- It communicates with the host and serves as an intermediate storage for messages. 
The interface to the host associates messages with a port number The interface to 
the TISS comprises the message together with routing and target host information. 

- It sends and receives messages at predefined periodical points in time over the 
TTNoC. Thereby it ensures that no collision of messages from different TISS occur 
inside the TTNoC. For this reason a static schedule has to be computed in advance 
for the entire TTSoC and each TISS is programmed accordingly. 

Figure |6] shows a core that communicates over a TTNoC using a TISS. Variables and 
their modifications are not shown. The TISS receives messages from the core and sends 
messages to the core. In case of incoming messages from the core, routing information 
is added to messages and they are transmitted over the TTNoC. Otherwise, the routing 
information is deleted and the message is given to the core. The TISS also serves as a 
kind of buffer, since TTNoC and core do not have to be synchronized. The BIP model 
comprises two locations 10 and 11. Messages may be received and collected at any 
time from the host system using the connector between the COre2tiss_io ports. The 
transmission and receiving of messages to and from he TTNoC happens only at the 
ttnoC-COmm transition from 11 to 10 while the global time tick performs a transition 
from 10 to II. This ensures that at most one message is either sent over or received 
from the TTNoC per global time tick from a single TISS. Incoming messages from the 
TISS are associated with a port number and stored intermediately. The port number is 
used to determine the target host and additional routing information. This resolvement 
happens during or before a ttnocxomm transition. Messages that are to be collected 
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Fig. 6: Connecting a host system to the TTNoC via a TISS 



from the host by the TISS are also stored in the TISS together with a port number The 
conditions when a message is actually sent during the ttnoc_COmm typically depends 
on additional internal variables that can, e.g., count global time ticks in the TISS during 
the tick transition. This ensure that different types of messages (e.g., associated with 
different ports) are only sent at predefined periodic points in time to predefined targets 
and remain in storage otherwise. 

4.3 Inside the TTNoC 

We refer to Figure |5] for on overview on the BIP components that represent a TTNoC 
and connectors and ports for message passing. Not shown in this figure are the means 
to emit and handle time ticks and the communication details. 

BIP models for switches A switch can handle one message per global tick. In our BIP 
model for switches in the described TTNoC we model this feature by introducing three 
states: 10, 11 and 12. 10 is the state before a message arrives. 11 is the state where a mes- 
sage has arrived but not transmitted, 12 represents a state where the arrived message 
has been forwarded to another TISS or switch, but some time is still remaining before 
the next global tick. The arrival of a message occurs together with tick or during t1 
or t2. The routing to the other switch or TISS happens in t1 , t2 or t3. If it happens in 
t3 we return to 10 immediately, otherwise we mark the switch as used by taking state 
12. Figure [T] gives an overview on a simple BIP model for the switch 2. It omits some 
communication details. The BIP models used in a more comprehensive implementa- 
tion feature additional intermediate locations not visible to the external to facilitate the 
handling of additional constraints. 

The TTSoC as a Component The TTSoC itself is modeled as a single composite BIP 
component comprising the switches, TISS components and connectors between these 
components. As interfaces it offers connections to the hosts and to the global time tick. 

4.4 Modeling the Host System 

In our case modeling a host system means the creation of BIP models that simulate 
the entire software that runs on a core and its execution characteristics. In the proposed 
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scenario a host system is composed of components that reahze: communication ser- 
vices, higher-level services, application code and I/O. Thus, the host is realized using 
different BIP components which may interact with each other. Unlike in the TTNoC 
different BIP components, e.g., representing different threads on the host core can run 
completely asynchronous. This may, e.g., be the case for different threads running on a 
CPU core. 

Communication Services Communication services represent software parts that real- 
ize some functionality that the application code may use. This can comprise operating 
system services and special hardware drivers. Here they are realized as BIP components 
that are connected to a TISS on the one side and to higher-level services, I/O, and ap- 
plication models on the other side. They simulate, services that we are implementing as 
part of a basic software support for our TTSoC. 

Higher-level Services Higher-level services are composed services that realize some 
higher-level functionality based on other services. Here we have modeled a voting ser- 
vice which takes several input values, e.g., from different sensors and establishes a mean 
value which is forwarded to the application. 

Application Code Component The application code is modeled as an atomic or com- 
posite single BIP component. A scenario with an application code component with 
connectors to other services is shown in Figure [8] 

Input / Output Components We provide BIP models that simulate Input and Output 
operations. These comprise simulation components that provide simulation of sensor 
data. Furthermore output components that simulate, e.g., actuators. In the current im- 
plementation these output components write their status data to files. 

Realizing a Host System Figure [9] shows the interaction of an application with a com- 
munication service. This interaction may occur asynchronously to the global time tick 
and the TTNoC. By means of this asynchronity we model the much faster execution 
clock speed of a core compared to the TTNoC. 

4.5 Application Code for Industrial Automation 

In this paper we target different application scenarios for the usage of TTSoC based 
systems in the industrial automation domain. Software for industrial automation is typ- 
ically described using the lEC 61131-3 |10| standard. These software descriptions di- 
vide computation into different steps which are often executed one after the other form- 
ing a kind of loop structure with branches. C code is typically generated for each of 
these steps individually. In the real system it is integrated into one large C loop struc- 
ture. Here we realize this loop like top level control structure in BIP as an LTS and 
integrate generated or hand written C code that realizes the functionality represented by 
the steps into the LTS transitions. This way, we have a device to test and simulate these 
generated or hand-written C code pieces and adapt them. 
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Fig. 9: Application and services on a core connected to a TISS 



API calls The generated or hand-written C code contains API calls (e.g., a POSIX API). 
Communication with BIP modeled services is done by using the same C API calls from 
the application code. However, the implementation is done in a slightly different way. 
Our C functions store and retrieve values from intermediate stores which are filled and 
collected by the services. The same principle is used in the real implementation so our 
simulation sticks close to it. In the real implementation services can, e.g., be realized as 
independent threads. 

Time The execution of a step is usually associated with a maximal execution time called 
time slice. In our model execution of the C code associated with a step is done during 
one state transition. Modeling the duration of this execution is done by requiring that a 
number of global time ticks (corresponding to the time-slice) have to be elapsed before 
the application code component is able to communicate its new result and control is 
passed to the BIP transition associated with the next step. 

We have described an additional transformation from lEC 61131-3 to BIP in IH. 
Unlike in this work, here we keep the BIP structure as minimal as possible in order to 
simulate the C-code pieces in the most realistic way. 



5 Application and Service Simulation for a Sorting Station 

Here we describe the application code for our sorting station as depicted in Figure [5] 



Figure 10 gives an overview on a possible setting: this study is inspired by a real 
existing demonstrator llT4ll . Six hosts are connected via a TISS to the TTNoC. One host 
comprises a core that executes the application software, another core is dedicated to a 
voting service that judges the quality of values delivered by sensors. Two hosts each 
perform the reading of sensor values and control of actuators. Each host features com- 
munication services to communicate via its TISS over the TTNoC with other hosts. 
The lEC 61131-3 structure that runs as application is sketched in Figure [TT| (cf. ||5|). 



The different steps are shown for which we integrate C-code in our BIP model of the 
application. The BIP model itself has a similar structure. The entire application is mod- 
eled as a single BIP component communicating with services. Transitions between steps 
are replaced by transitions between BIP locations. Additional transitions are inserted to 
handle I/O at the end of each step. Each step is modeled in a way such that it terminates 
in a fixed amount of time. This is a typical feature in lEC 61 131-3 that we took care of 
here. 
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Fig. 10: Overview on a configuration scenario 



Common to all scenarios is that the application is running on different cores than 
I/O operations and has to communicate with and control the I/O. In our real systems 
the TTSoC is reaUzed using FPGA technology. In principle it is possible to adapt the 
number of cores and the layout of the TTNoC to application needs. Furthermore, cores 
can be specialized towards distinct domains of computation and I/O. The number of 
API calls in the appUcation C-code is very small: just Posix calls to receive and transmit 
messages. 

6 Evaluation 

We have run and analyzed different system configurations using our BIP models of 
TTSoC components, services and appUcation code. All of them realize different simu- 
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Fig. 11: lEC 61131-3 control structure 



lation scenarios for the industrial automation domain (cf. Section|5 1. In particular they 
are based on our application for the sorting station shown in Figure T] 

The simulation gives us the ability to test and improve our application software. By 
omitting and modifying priorities of interactions different non-deterministic scenarios 
can be simulated. Due to this testing we where able to fix some minor errors in the 
actual C-code implementation. More importantly our simulation revealed the following 
weakness of our overall sorting service control strategy: it can occur that the application 
receives old sensor data and actuator commands are not delivered on time. The main 
reason for this is that the communication between the application and the TISS happens 
asynchronously and without a timing guarantee. 

One solution to overcome this drawback would be to change the design of the 
system and establish a synchronous communication between application software and 
TISS at distinct points in time. This, however would require major changes in the sys- 
tem design. For this reason we analyze application software parts to estimate a worst 
case execution time. This can be used to determine a maximal latency for reaction of 
the application software to sensor data and control of actuators. The overall speed of 
processing elements in the sorting station will be set such that these latencies do not 
lead to a wrong handling of an element. 



7 Conclusion 



We showed a way to simulate and validate aspects of TTSoC based systems at an early 
development stage. We presented BIP models for representing hardware components of 
TTSoC based systems. Furthermore, we introduced BIP models for connected software 
services. These models provide an environment for simulating TTSoC based systems 
prior to deployment and availability of exact specifications. They can be used for a vari- 
ety of TTSoC usage scenarios. We exemplified a case study from the industrial automa- 
tion domain. Here the main purpose is simulating the controlling software parts (appli- 
cation) prior to availability of the entire system. Thereby we introduced a way of model- 
ing and simulating PLC applications using BIP. Running our simulations we discovered 
additional timing constraints which have to be ensured in the real-implementation of the 
system. 

As future work, we plan to investigate additional case studies in other domains. Fur- 
thermore, we are also interested to formally analyze properties of our models. These 
comprise analysis of invariants and related properties like deadlock freedom by using, 
e.g., D-Finder 2 |[3|. An extension to real-time aspects is also a goal. Another, area 
for future work is the connection of the input and output components to software that 
graphically displays the status of an industrial automation device, so that one can ac- 
tually see a virtual video of a machine that sorts work pieces controlled by our BIP 
components. 

Acknowledgments This work has been supported by the European research project 
ACROSS under the Grant Agreement ARTEMIS-2009- 1-100208. 

References 

1. F. Balarin and Y. Watanabe and H. Hsieh and L. Lavagno and C. Passerone and A.L. 
Sangiovanni-Vincentelli. Metropolis: An Integrated Electronic System Design Environment, 
IEEE Computer, volume 36, issue 3, pages 45-52, 2003. 

2. A. Basu, M. Bozga, and J. Sifakis. Modeling Heterogeneous Real-time Components in BIP. 
Software Engineering and Formal Methods. IEEE, 2006. (SEEM' 06). 

3. S. Bensalem, A. Griesmayer, A. Legay, T-H Nguyen, J. Sifakis, and R. Yan. D-Finder 2: 
Towards Efficient Correctness of Incremental Design. NASA Formal Methods Symposium, 
2011. (NFM'll) 

4. I. O. Blech, A. Hattendorf, J. Huang. An Invariant Preserving Transformation for PLC Mod- 
els. IEEE International Workshop on Model-Based Engineering for Real-Time Embedded 
Systems Design, 20 11. 

5. I. O. Blech and S. Ould Biha. Verification of PLC Properties Based on Formal Semantics in 
Coq. Software Engineering and Formal Methods , 201 1. accepted (SEEM' 11) 

6. M. Bozga and S. Graf and I. Ober and I. Ober and I. Sifakis. The IF Toolset, LNCS vol. 
3185, Springer-Verlag,2004. 

7. PH. Feiler. The SAE Architecture Analysis & Design Language (AADL). SAE International 
Document AS-5506A, Revised Ian 2009. 

8. E. A. Lee. Disciplined Heterogeneous Modeling. ACM/IEEE International Conference on 
Model Driven Engineering, Languages, and Systems , D.C. Petriu, N. Rouquette, O. Haugen 
(eds.), LNCS 6395, Springer- Verlag, 2010. (MODELS' 10) 



9. C. Paukovits and H. Kopetz. Concepts of Switching in tlie Time-Triggered Network-on-Cliip. 
14th IEEE International Conference on Embedded and Real-Time Computing Systems and 
Applications, 2008. 

10. Programmable controllers - Part 3: Programming languages, lEC 61131-3: 1993, Interna- 
tional Electrotechnical Commission, 1993. 

11. J. Ruf and D. Hoffmann and J. Gerlach and T. Kropf and W. Rosenstiehl and W. Mueller. The 
simulation semantics of systemC. Conference on Design, Automation and Test in Europe, 
IEEE Press, 2001. (DATE '01) 

12. B. Selic. Tutorial: An Overview of UML 2.0. International Conference on Software Engi- 
neering , IEEE, 2004. (ICSE '04) 

13. The Coq proof assistant. http://coq. inria.fr/\ 

14. Specification of Industrial Control Application Demonstrator WP6. Deliverable 6.6 of the 
ACROSS project. http.V/www.across-project. eu/download/ACROSS-D6. 6.pdf 

15. L. Thiele, I. Bacivarov, W. Haid, K. Huang. Mapping Applications to Tiled Multiprocessor 
Embedded Systems. 7th Intl Conference on Application of Concurrency to System Design , 
IEEE , July, 2007. (ACSD 2007) 



Appendix 



A version of our TTNoC model with port names is shown in Figure 12 
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Fig. 12: TTNoC model overview 



